…UX polish

Addresses review issues found before staging promotion. Most are wiring
gaps exposed once the flag was flipped ON and the read path started
actually consuming rowMatchState + conceptCache.

Correctness:
- pickTopRowView reads target canonical from buildProjectContext() (the
  same source the normalizer used to stamp ConceptDefinition.reference.url),
  not from the caller's _repo arg. Eliminates the derived-vs-explicit
  canonical mismatch that silently emptied auto-match.
- Centralize concept_identity injection in ensureConceptIdentity() inside
  algorithms.jsx. Handles built-ins, API-loaded bridge/scispacy, and
  custom algos via user-entered canonical_url. Replaces three inline
  reconstructions in MapProject.jsx (getAlgoDef, bulk processBatch path,
  lookupCandidates) and the legacy load path. Also fixes a latent bug
  where custom-algo canonical_url was never wired into a concept_identity
  block so the field had no runtime effect.
- matchRerankResultToKey throws on canonical-identity miss; the rerank
  loop collects errors, logs them, and surfaces a single summary alert.
  Dropped the fuzzy ocl_url / id+source fallbacks — the unified-model
  spec relies on canonical identity and silent fallback was masking
  config gaps.
- mergeIntoRowMatchState auto-triggers ensureLoaded for newly-arrived
  ConceptDefinitions with lookup_status !== 'full' (bridge cascade
  targets, sparse algorithm results). Plan called for state-driven
  $lookup; PR2b had the helper but no automatic trigger. Forward-ref
  pattern (ensureLoadedRef) matches existing scheduleRerankRef.
- fetchAndSetProject: when a saved project has match data but no target
  canonical can be resolved, surface an error alert and force-open the
  configuration drawer (setConfigure(true)) instead of silently rendering
  an empty candidate list under the flag-ON read path.

Click-path wiring (rowView <-> legacy concept shape at the seam):
- Candidates.jsx decorates rowViews with top-level id/url/version_url so
  SearchResults.handleRowClick (which looks up rows by those fields) can
  resolve clicks back to the rowView. Without this, the candidate row
  click never fired onShowItemSelect.
- Concept.jsx passes the conceptForMapping projection (not the raw tuple)
  to setShowHighlights so SearchHighlightsDialog finds
  search_meta.search_highlight (Matched Attributes).
- viewBuilders.getScoreDetails accepts either the {candidate, conceptRow}
  tuple or the legacy {search_meta} shape, so the dialog's score chip
  works regardless of which form the caller sends.

Save-time validation:
- Custom algos require a valid canonical_url (URL-pattern check). Save
  button disabled and a structured Alert lists offending algos. The
  inline TextField helperText also distinguishes missing vs malformed.
  Exported getProjectConfigErrors() + isLikelyCanonicalUrl() from
  algorithms.jsx as the single source of truth.

CSV export:
- __map_repo_url__ and __map_repo_id__ are now gated on `concept` (the
  mapSelected entry) so they're blank on unmapped rows. Matches the rest
  of the __map_* namespace (concept_id/name/url were already empty on
  unmapped rows) — drops the asymmetric project-repo fallback that
  predated PR2b.

UI polish + i18n:
- Compact canonical-URL caption under target repo (info icon + monospace
  URL with ellipsis truncation + tooltip + muted 'derived' suffix).
  Bridge repos use the same line per bridge. Replaces the orange chip
  that read like an error.
- All PR2b-introduced t() calls switched from `t(key) || 'default'`
  (which never falls through because i18next returns the truthy key
  string) to `t(key, 'default')` / `t(key, {defaultValue, ...interp})`.
- Added the PR2b string set to en/translations.json (target_canonical_url,
  canonical_auto_derived_short, bridge_canonical_short, advanced_settings,
  resolution_namespace + description with {{owner}} interpolation, the
  algo_canonical_url_* family, config_errors_title, target_repo_required_
  on_load, etc.). resolution_namespace_description now spells out the
  default ('When blank, defaults to {{owner}}'). Other locales inherit
  via fallbackLng='en'.

No new tests required — covered by existing 79/79 suite. Bridge /
scispacy / AI Assistant paths still need staging verification (per the
PR description).

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…fied-score chip

Interim semantic-search candidates were rendering with a 100% unified
score until the debounced $rerank/ pass landed. Cause: viewBuilders
.getScoreDetails fell back to candidate.score * 100 when
conceptRow.rerank_score was undefined. Semantic search returns top
candidates with raw score ≈ 1.0 (cosine similarity placeholder), so the
scaling produced 100% for every result during the interim. After rerank
completed, the chip updated to the real value — wrong AND misleading
during the window.

Removed the fallback. percentile stays undefined when no rerank score
exists; rerankScore becomes ''. Score.jsx renders a muted em-dash in
the unified slot when rerankScore is empty so the chip stays present
but neutral. Quality bucket coloring also goes neutral until rerank
lands. Single-algo native paths (ocl-search with reranker:true)
already get search_normalized_score from the $match response, so
rerank_score is populated on first arrival — those paths are unaffected.

Updated the existing viewHelpers test that asserted the old fallback
behavior; it now documents that an interim candidate with no rerank
score yields hasPercentile=false, no qualityBucket, and a raw algoScore
chip but no unified chip.

Verified: 79/79 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…b visits with zero matches

fetchScispacyCandidates gated its short-circuit on existingCandidates
.length > 0. A successful scispacy invocation that returned zero
matches writes {row, results: []} into allCandidates — the array exists
but is empty. The .length > 0 check failed for those rows, so every
time the user switched away from the Candidates tab and back, the
algo re-ran. Rows where scispacy found at least one match correctly
short-circuited; the bug was specific to the zero-result case.

Gate on entry presence instead. find(...) returning a defined entry
means the invocation completed and was persisted; that's the signal
we want to skip on. Empty-results rows now skip on revisit; failures
still retry because the catch block markAlgo(-2)s without writing an
entry, so find returns undefined and the path falls through to a
fresh attempt.

Verified: 79/79 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…bridge_child rows in algo view

Bridge_child rows (cascade targets nested under their bridge intermediary)
in the Group by Algo view were rendered with noScore={algoScoreFirst}.
algoScoreFirst is always true in algo view, so the Score component was
suppressed entirely — no raw chip (correct, bridge response doesn't
score targets) AND no unified chip (wrong, the row's rerank_score is
meaningful per-(row, concept)).

Dropping the prop lets Score render. The unified chip surfaces from
conceptRow.rerank_score; the raw chip stays absent because
candidate.score is undefined for bridge_child (normalizers.js line 256)
and Score's hasRawScore guard skips the parenthetical algoScore slot.

Verified: 79/79 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… for scispacy candidates

Scispacy unified-score chips were showing the raw composite_score
multiplied by 100, masquerading as a rerank score. Cause:
fromScispacyResultsToConcepts pre-populated
search_meta.search_normalized_score = composite_score * 100. The
normalizer reads search_normalized_score directly into
ConceptRow.rerank_score (normalizers.js:178), so the synthesized value
became the row's "rerank score" before the debounced $rerank/ pipeline
got a chance to fill it in — and once set, the rerank-loop overwrite
path generally didn't replace it.

The user-visible disparity (0.64 raw, 64.29% unified) was the same
number to different precision: composite_score ≈ 0.6429 displayed as
"0.64" via toFixed(2) on one chip, "64.29%" via composite_score * 100
on the other. Not actually a rerank score.

Drop the normalized_score synthesis. Scispacy ConceptRows now enter
rowState with rerank_score: undefined; scheduleRerank already covers
the multi-algo and ocl-scispacy paths (MapProject.jsx:2582) and the
matchRerankResultToKey path resolves scispacy's canonical_url=loinc.org
identity correctly. With the score*100 fallback removed in 9fcdbb2,
the chip shows a muted em-dash during the interim and switches to the
real rerank value when $rerank/ completes.

Verified: 79/79 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…Children

Two bugs in the Group by Algo view sort.

onSort silently flipped same-option clicks to Unified.
The old conditional `if(option === sortBy || option === 'rerank_score')`
treated re-clicking the currently-selected sort option as a switch to
rerank_score. In algo view sorted by Raw, clicking "Raw" again silently
moved the user to Unified — the toolbar selection looked correct one
moment and not the next. Rewritten as a plain assignment: setSortBy
gets whatever the user clicked. The implicit group-switch when picking
'algo_score' stays (raw scores aren't comparable across algos in the
Quality grouping, so Raw really does imply algo view).

Bridge cascade targets weren't sorted within their parent bridge.
buildAlgorithmRowViews emits bridgeChildren in normalization order with
no internal sort. For SAME-AS bridges with one target this is invisible,
but bridges with multiple cascade targets rendered them in arbitrary
order. getCandidates now applies sortRowViews to each bridge's children
with the same sortBy/order as the top-level. Children don't have their
own raw score; sorting by algo_score leaves them in insertion order via
sortRowViews' -1 sentinel — acceptable, and Unified sort lands them
correctly by their per-row rerank_score.

Verified: 79/79 tests pass. Pre-existing lint errors in Candidates.jsx
(unused candidateToRowView import line 52, unused arr destructure line
402, both introduced in 41057bf) are unchanged by this commit.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

In Group by Match Quality, bridge cascade targets rendered only the
target concept's source:id+name preceded by the map_type chip. The
bridge intermediary (e.g. CIEL when target is LOINC) was dropped from
the row entirely — the user had no inline signal of *which* bridge
concept reached the target, even though the data was already on
bridgeConceptDefinition.

Two sub-cases, two behaviors:

(a) Bridge-only — the target was reached ONLY via the bridge. Concept.jsx
Item's bridgeChild branch now renders the full cascade inline:
  CIEL:1234 ciel-name [SAME-AS] LOINC:52767-1 loinc-name

(b) Convergence — the target was reached by BOTH a standard algo and one
or more bridges. The standard candidate is preferred as the primary (as
before), so the row renders as a normal LOINC entry. To preserve the
bridge story without cluttering the primary line, the new
bridgeContributors array on the rowView feeds an [i] indicator next to
the algorithm chip in the secondary row. Hover yields a tooltip:
  "via CIEL:1234 ciel-name — SAME-AS"
Multiple bridges on the same target stack as separate tooltip lines.

Implementation:
- viewBuilders.buildQualityRowViews emits bridgeContributors: an array of
  {bridgeConceptDefinition, map_type, algorithm_id} for every
  contributing bridge_child candidate *other than* the primary. Bridge-
  only rows (primary IS bridge_child) have empty bridgeContributors —
  the inline framing already shows the bridge, no need for a duplicate
  indicator.
- Concept.jsx Item splits the primary-line render into bridgeChild
  (inline framing) and non-bridgeChild branches. The algo-chip secondary
  line picks up the InfoOutlined icon when convergenceTooltip is
  non-empty.

Tests: two new cases in views.test.js — convergence yields a non-empty
bridgeContributors entry with the right def/map_type/algorithm_id;
bridge-only yields an empty array.

Verified: 81/81 tests pass, eslint clean, production webpack build
green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ty on algo responses

Half of every input row's candidates rendered without their LOINC summary
chips (COMPONENT/PROPERTY/TIME_ASPCT/etc.) in the card view. Diagnostic
logging in Concept.jsx (added then removed in this branch) confirmed all
affected candidates had:
  - algorithm_id: 'ocl-semantic'
  - lookup_source_type: 'algorithm' (never upgraded by ensureLoaded)
  - empty `concept.property` and empty `concept.properties`

Root cause was client-side, not server-side. OCL $match with verbose=true
already returns ConceptDetailSerializer output, which includes
`property = JSONField(source='properties')` — the schema dict UI reads at
ConceptSummaryProperties.jsx:22. oclmap was already passing verbose=true
on every $match call. Two bugs in normalizers.js dropped the data on
ingest:

1. toConceptDefinition's explicit field-copy list (lines 105-127) didn't
include `property` or `extras`. Even when the verbose response had them,
the normalizer threw them away before they reached conceptCache. Added
both fields to the copy list with a comment pointing at the API surface
they correspond to.

2. inferLookupStatus required BOTH `names` AND `descriptions` arrays for
'full' status. Many LOINC concepts have no separate `descriptions` (the
LONG_COMMON_NAME is in `names`, schema fields are in `property`/`extras`)
— they stayed stuck at 'partial' even when verbose-loaded, which
triggered spurious ensureLoaded retries and produced misleading log
signal. Reworked the heuristic: 'full' now means the response carries
a verbose-payload marker (`property` field present — ConceptDetailSerializer
always emits it, even as []), OR has populated `names` (the list-
serializer signal). Explicitly DOESN'T check `extras` because scispacy
synthesizes that field with internal metadata (LOINC_NUM, composite_score)
and would false-positive into 'full'.

Tests added in normalizers.test.js:
- verbose response with populated `property` → full + property captured
- verbose response with `property: []` → still full (marker, not length)
- brief response without `property` or `names` → stays partial

No server-side change needed. The "smart enough to detect partial vs full
and do the lookup" behavior that was already in place now works because
the lookup_status field accurately reflects payload completeness.

Verified: 84/84 tests pass, eslint clean, production build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…zed_score in multi-algo mode

Interim semantic candidates still rendered "100.00%" unified-score chips
until $rerank/ completed — the score*100 fallback drop from 9fcdbb2
didn't fix this case because the score wasn't coming from the fallback.
It was coming from search_meta.search_normalized_score, which the OCL
$match endpoint emits UNCONDITIONALLY (line 878 of oclapi2 views.py
sets it to FAISS normalized_score × 100). For top semantic hits the
value rounds to 100. The normalizer at newConceptRow read that straight
into ConceptRow.rerank_score even in multi-algo mode where it's just a
per-algo native score, not a unified rerank.

Threaded trustServerRerank through the normalizer context:

  normalizeAlgorithmInvocation(payload, { trustServerRerank }) →
    normalizeAlgoResult(result, { trustServerRerank }) →
      newConceptRow(key, result, trustServerRerank)

newConceptRow now propagates search_normalized_score to rerank_score
ONLY when trustServerRerank is true. Call-site values:

- Bulk auto-match processBatch (line 1496): !isMultiAlgo. The $match
  request at line 1433 sends reranker=!isMultiAlgo, so the response's
  normalized score is a real rerank only when single-algo.
- Per-row $match (lines 2528, 2551): !isMultiAlgo && provider==='ocl'.
  Matches the line 2452 request flag and the line 2579 "rerank done"
  condition.
- Bulk bridge (line 1687) and bulk scispacy (line 1731): omitted →
  defaults to false. Bridge's normalized score doesn't speak the
  project's query semantics; scispacy never had a real rerank.
- normalizeLegacyAllCandidates: true. Saved-project rerank scores were
  persisted from a prior session's $rerank/ output, so they ARE the
  canonical rerank.

UX consequence with the 9fcdbb2 fix in place: during the gap between
multi-algo $match returning and $rerank/ completing, the unified chip
renders a muted em-dash instead of a misleading 100.00%. When rerank
lands, real scores appear. When a slow algo (scispacy) returns later,
its rows briefly show "—" again until the next rerank pass — that's
expected behavior given the staggered timing; the double-rerank itself
is a known cost (Bug 9 follow-up: debounce more aggressively or wait
for all-algos-complete).

Tests updated:
- normalizers.test.js: added a multi-algo case asserting search_
  normalized_score is ignored when the caller doesn't opt in; updated
  the bridge ConceptRows test to expect undefined rerank_score (bridge
  path doesn't opt in); updated the single-algo carry-over test to
  pass trustServerRerank: true.
- normalizeLegacyAllCandidates.test.js: unchanged — the legacy loader
  passes trustServerRerank: true, so its tests still see baked-in rerank
  scores.

Verified: 85/85 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ack a score

scheduleRerank's debounce window (~200ms) is far shorter than the gap
between fast algos (semantic, bridge — seconds) and slow ones (scispacy
— minutes). When scispacy lands late, a second $rerank/ fires for the
same row — but the implementation re-reranks EVERY ConceptRow, not just
the new ones. For a row with 50 candidates from semantic + 20 from
scispacy, the second pass redoes the 50 already-scored rows for no
reason.

buildRerankRowsForRow now skips ConceptRows whose rerank_score is
already a number. The cross-encoder reranker is per-(query, candidate)
so scores from successive partial batches stay on the same scale; the
filter is safe.

Net effect:
- Rerank #1 (after semantic+bridge): scores all available ConceptRows.
- Scispacy arrives 2 minutes later: its new ConceptRows have
  rerank_score=undefined.
- Rerank #2: payload includes ONLY the new scispacy rows. The old
  semantic+bridge rows are skipped — their scores persist.

If a previously-scored row's score is somehow cleared (e.g. cache reset),
it becomes eligible again on the next scheduleRerank fire. Refresh path
still works: mergeIntoRowMatchState's drop-and-replace from 2d96c09
prunes ConceptRows whose candidates were removed, so refresh creates
fresh unscored rows and rerank picks them up.

Verified: 85/85 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…'s reuse check with the inner fetchers

Companion to b0e8d52 (scispacy fix). That commit only patched
fetchScispacyCandidates's gate; the outer fetchAllCandidatesForRow still
gated on results.length > 0. Sequence when scispacy returned zero
matches on a prior fetch and the user clicks the row again:

  fetchAllCandidatesForRow(scispacy) sees results.length === 0
  → canReuseExistingCandidates = false
  → markAlgo(scispacy, 0)  // "Running: ocl-scispacy-loinc" indicator on
  → dispatches to fetchScispacyCandidates
  fetchScispacyCandidates sees existingEntry !== undefined (correct)
  → returns { skipped: true }, no callback fired
  onResponse never invoked → no algo_finished log → markAlgo stays at 0
  → indicator pinned forever; in worst case scheduleRerank also stuck
  waiting for the marker that never lands

Same fix: gate reuse on entry presence, not result count. Empty-result
rows now correctly short-circuit through the reuse branch — markAlgo(1),
recurse to next algo, schedule rerank — exactly like a non-empty-result
reuse would.

forceReload still bypasses (user-driven refresh). offset > 0 still
bypasses (Fetch More pagination). _retired flip still bypasses (user
toggled retired-concept inclusion).

Verified: 85/85 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…flight guard

The Decision panel's tab handler was re-firing the full algo chain on
every switch back to the Candidates tab. Two compounding bugs:

  const firstAlgo = getFirstAlgoDef()?.id   // already a string
  if(... && !find(allCandidatesRef.current[firstAlgo?.id], ...)?.results?.length) {
                                  // ^^^ string?.id is undefined
    fetchAllCandidatesForRow(firstAlgo.id)
                             // ^^^^^^^^^^^ also undefined → falls through
                             //     to 'use first algo if no algoId'
  }

The cache-presence test always missed (allCandidatesRef.current[undefined]
returns undefined), so the refetch always fired even when candidates were
already loaded. fetchAllCandidatesForRow(undefined) → uses the first algo
anyway, so the user-visible effect was the chain re-running.

Additionally: no in-flight guard. If the user clicked a row, switched to
Discuss before the first algo finished, then switched back to Candidates,
the chain refired CONCURRENTLY with the still-running first chain.
Result: duplicate algo_finished log entries (ocl-semantic logged at
2:01:18 and 2:01:19 for the same row) and double rerank invocations.

Fix:
- Compute firstAlgoId once and use it directly (no .id chain).
- Skip the refetch when any selected algo for this row is currently in
  flight (rowStageRef.current[rowIndex][id] === 0). The status-0 marker
  is set at fetchAllCandidatesForRow line 2499 the moment a dispatch
  begins, so this catches the race window cleanly.
- Use Boolean(find(...)) instead of .results.length to test presence —
  same fix class as 6697c52 and b0e8d52 (an algo that returned zero
  matches is still "loaded").

Verified: 85/85 tests pass, production build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…r Bug 9 rerank filter

Bug 9 (0ae57dd) made buildRerankRowsForRow skip ConceptRows that already
have a rerank_score, so the second rerank wouldn't redundantly re-score
the first batch. That filter applied to ALL rerank invocations,
including the explicit bulk-auto-match call.

Race that caused the regression:
  1. Bulk auto-match runs every selected algo (Promise.all on algoPromises).
  2. Each algo's onResponse calls scheduleRerank(__row.__index) — debounced,
     isBulk=false.
  3. The debounced rerank fires and scores every ConceptRow for the row.
  4. processRerankWithConcurrency loops over rows and calls rerank(idx, true)
     — isBulk=true.
  5. buildRerankRowsForRow finds zero unscored rows (the debounced pass
     scored them all). rerank() short-circuits at the empty-rerankRows
     guard and returns null.
  6. setAutoMatched is wired to the isBulk=true success path (line ~2829
     setTimeout setAutoMatched), so the short-circuit drops the side effect.
     User clicks Auto-Match, sees algos finish, sees rerank finish — and
     no row with a clearly-recommended top candidate gets proposed.

Fix: when rerank() short-circuits with isBulk=true (no work needed, the
debounced pass already did it), still schedule setAutoMatched. The rows
ARE scored; the bulk caller just needs to be told to propose mappings.

Verified: 85/85 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…iew bridge polish

Three small Concept.jsx fixes uncovered in browser testing.

map-type chip styling.
The MUI Chip with size='small' was still tall enough to interrupt the
surrounding text's line-height — visible as a vertical bump in cascade
rows like "CIEL:1234 ... [SAME-AS] LOINC:52767-1 ...". Pulled out a
MAP_TYPE_CHIP_SX constant: 18px height, 11px label, tight 0/6px label
padding, baseline vertical alignment, 4px radius. Sits inline with the
text now.

Algo-view bridge children no longer repeat the bridge prefix.
In Group by Algorithm, the parent bridge intermediary ConceptItem is
already rendered above its nested cascade targets. The bridgeChild Item
branch (added in 571a12b for Quality view) was rendering the prefix on
every nested line too, so the same "CIEL:166016 Brain natriuretic..."
appeared three times in a row. Gate the prefix render on
!algoScoreFirst — Quality view still gets the full cascade inline,
Algo view gets the cleaner "[BROADER-THAN] LOINC:42637-9 ..." per child.

First bridge-child row in algo-view was missing its top divider.
ConceptItem suppresses borderTop when firstChild={true}, and bridge
children inherited that flag through baseProps when the bridge group
itself was the first ConceptItem in the algorithm bucket. Explicitly
pass firstChild={false} on every bridge-child render — there's always
a parent intermediary above them, so the divider belongs.

Verified: 85/85 tests pass.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…Quality view

Candidates arriving before $rerank/ completes were being shunted into
Low Ranked Candidates. The bucketing logic at getCandidates used
`score = view.conceptRow?.rerank_score || 0`, which coerced undefined
to 0 — every unscored row failed the recommendedScore / availableScore
thresholds and landed in low_ranked. Visually that read as "these are
poor matches" when the truth is "we don't know yet, rerank is pending".

Bucketing now keys on score presence first:
  if typeof score !== 'number' → pendingRerank
  else recommended / available / low_ranked

Rendered as a fourth section at the bottom of Quality view with a
neutral gray PENDING_RERANK_COLOR indicator. Header reads "Unranked
Candidates" (translation key already existed at en.json:514 unused).
Section only renders when pendingRerank.length > 0; once rerank lands
on every ConceptRow it disappears and rows have already redistributed
into their proper score buckets.

Translation key was already in en/translations.json; no other locales
touched (fallbackLng='en' covers them).

Verified: 85/85 tests pass, production build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

… when repo canonical resolves

Saved projects reloaded with non-scispacy candidates missing from every
row. Quality view rendered empty or scispacy-only; the data was loaded
correctly into allCandidates and project history was intact, but
Candidates.jsx filters Quality-view rows on
view.conceptDefinition.reference.url === targetCanonical and the
references didn't match.

Root cause is an async ordering race in fetchAndSetProject:

  1. Project GET returns. response.data has target_repo_url but the save
     format never persisted target_repo.canonical_url.
  2. setProjectFromData fires fetchRepo(repoURL, _repo) — promise NOT
     awaited.
  3. Same tick: loadProjectContext is built with the FALLBACK derived
     canonical (https://ns.openconceptlab.org{relurl}). normalizeLegacy-
     AllCandidates stamps every ConceptDefinition.reference.url with it.
  4. Later: fetchRepo resolves, repo state lands with the REAL canonical
     (e.g. http://loinc.org for LOINC). buildProjectContext computes
     targetCanonical from this real value, passed as a prop to Candidates.
  5. Quality view filters by reference.url === targetCanonical:
     'https://ns.openconceptlab.org/orgs/Regenstrief/sources/LOINC/' vs
     'http://loinc.org' → no match → empty list.
  6. Scispacy uses reference_source: 'fixed' with a hardcoded
     canonical_url, so its references are stamped 'http://loinc.org'
     regardless of projectContext — and survive the filter. Hence the
     "only scispacy shows" symptom.

Two-part fix:

(a) On save, persist target_repo.canonical_url (plus owner/source/version
metadata) alongside target_repo_url. Future loads pick up the canonical
on first read; no fetchRepo wait.

(b) For older saves without target_repo.canonical_url (and for any
post-load repo change), a useEffect on buildProjectContext re-runs
normalizeLegacyAllCandidates whenever the live target canonical differs
from the one used for the last normalize. lastNormalizedCanonicalRef
guards against re-running on identical canonicals — idempotent.

normalizeLegacyAllCandidates already takes a projectContext arg, so the
fix is plumbing only — no normalizer changes.

Verified: 85/85 tests pass, production build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Four fixes from @paynejd's local prod build exercise. Bridge children
sort + table-view properties are the cosmetic items from Test B; AI
Assistant POST + auto-fetch of target_repo canonical are the load-
bearing functional fixes. Test B indent/wrap deferred (CSS-only,
needs DOM probing).

#F — AI Assistant POST never fires (GET works).
fetchRecommendation's candidate-count gate sourced from legacy
allCandidates only. Any flow that ends with populated rowMatchState
but empty allCandidates (saved-project load races, future paths that
skip the parallel legacy write) bailed at `_candidates.length > 0`
before the POST. Now falls back to projecting unified state via
conceptForMapping when legacy is empty. buildV2RecommendationPayload
gets the same treatment: prefers rowMatchState + conceptCache directly
(the authoritative source under UNIFIED_MODEL_ENABLED), with the
legacy normalize-over-allCandidates path as fallback.

Test B — Bridge children non-deterministic sort.
buildAlgorithmRowViews preserved Object.values(rowState.candidates)
insertion order for nested bridge children. Same project rendered
differently between refreshes. New sortBridgeChildren helper orders
by rerank_score desc (when present), then concept code/id ascending.
Stable + meaningful — high-scoring cascade targets surface first.

Test B — Table view rendered without LOINC schema properties.
conceptForMapping projected `properties` (plural) but
ConceptSummaryProperties reads `property` (singular, the schema-
specific dict OCL returns for LOINC: COMPONENT/PROPERTY/TIME_ASPCT/...).
Card view worked because it gets the ConceptDefinition directly; table
view's rowsForTable spread only had what conceptForMapping returned.
Adding `property` and `extras` to the projection puts the schema chips
back in the table.

Test E — Scispacy candidates returned by API but not shown in UI.
Root cause: Quality view filter compares
`ConceptDefinition.reference.url === targetCanonical`. Scispacy uses
a FIXED canonical ('http://loinc.org', per CONCEPT_IDENTITY_BY_TYPE).
When the project's target_repo lacks canonical_url in its loaded
metadata (RepoSearchAutocomplete returns brief data), the live
canonical falls back to `https://ns.openconceptlab.org{relurl}` —
mismatch, filter excludes every scispacy candidate.

Fix: auto-fetch the target repo's canonical_url on selection (mirrors
MultiAlgoSelector's bridge_repo canonical fetch in fdc60b8). The
re-normalize useEffect from 45416ea then re-stamps any already-
normalized ConceptDefinitions to the live canonical. fetchedRepoCanonicalUrlRef
guards against re-fetches when the user toggles between repos.

For projects targeting a real LOINC repo (canonical_url=http://loinc.org
in OCL metadata), this restores parity: scispacy results pass the
Quality view filter. Projects targeting a custom LOINC subset (no
canonical_url, falls back to derived) still need a follow-up — the
fundamental issue is that scispacy's "I always return LOINC codes"
shouldn't be filtered out just because the target repo happens to be
a LOINC variant — track separately if reported.

Tests: 86/86 pass, eslint clean, production webpack build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Three fixes from @paynejd's round-5 verification: AI payload metadata
trim, scispacy alert copy update, and bridge_child indent (finally —
the previous CSS-padding shot did not match what the user wanted).

AI Assistant — strip heavy metadata from legacy candidates payload.
The "max_tokens 64000 / can only afford 62098" error is a server-side
output-budget / credits limit (the prompt template's max_tokens param
in ocl-ai-assistant), not an input-size issue per se. Verified on the
client side anyway: the legacy `candidates[]` field only stripped
`_source`, leaving `extras` (LOINC source-specific data, huge),
`names` (multiple locales), `descriptions` (multiple, often long) in
every candidate sent to the LLM. The v2 `recommendable_concepts`
field already omits these. Now `stripHeavyFields` drops `_source`,
`extras`, `names`, `descriptions` from each legacy candidate. Keeps
the fields the legacy prompt template needs (id, display_name, source,
search_meta, url, concept_class, datatype, retired, mappings,
property). Reduces tokens regardless of whether it solves the
specific credit error.

Scispacy alert copy.
Replaced the previous "Scispacy service unavailable (HTTP 503)..."
message with the user's preferred phrasing:
  "OCL's scispacy matching service is starting up. This may take a
   couple minutes. You can safely leave this row and come back. Click
   Refresh if results aren't here in a couple of minutes."
Applied to both the response-handler error branch and the .catch
network-error branch.

Bridge_child indent — proper flex layout (not CSS padding).
The previous attempt (paddingLeft: 6px on the secondary div) didn't
work because the BROADER-THAN chip is ~100px wide, the SAME-AS chip
~70px; a fixed 6px padding can't compensate. Restructured Item's
return so when useFlexLayout is true (bridge_child with map_type),
the chip becomes a SIBLING flex column to ListItemText. Both the
primary text AND the secondary text inside ListItemText then align
to the chip's right edge, regardless of chip label width:

  ┌──────────────┬────────────────────────────────────┐
  │ [BROADER-THAN]│ LOINC:14635-7 25-hydroxyvitamin D3 │
  │              │ COMPONENT: Calcidiol PROPERTY: ...  │
  └──────────────┴────────────────────────────────────┘

The chip is dropped from the primary span when useFlexLayout is on
(the bridgeChild path checks `!useFlexLayout && candidate?.map_type`
before rendering the inline chip). Non-bridge rows are unchanged —
ListItemText renders directly without the flex wrapper. The
overflowWrap/wordBreak rules from the prior commit remain.

Tests: 86/86 pass, eslint clean, production webpack build green.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…empts

Per @paynejd: "revert the bridge-child indent -- this is not what i
asked for and does not work. keep the other two."

Reverts Concept.jsx to its state at 22eaa6a (pre-attempt). Drops both
attempts at fixing the bridge_child secondary alignment:

  - 48dc6b5 (round 5): paddingLeft: 6px hack on the secondary div.
    Wrong magnitude — the chip is wider than 6px and varies by label.
  - 0e5805e (round 6): flex layout extracting the chip into a sibling
    column. Tested green but the user reports it does not match their
    intent.

The other two round-6 fixes — MapProject.jsx AI payload trim and the
scispacy alert copy — are unchanged.

Status: the bridge_child secondary alignment remains an open visual
issue. Need clarification on the desired layout (where should the
COMPONENT/PROPERTY/etc. line start relative to the [SAME-AS] chip and
the LOINC code text?) before another attempt.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…ttings overlay | extracted advanced settings component